Vormide valideerimise meisterlikkus Reacti `experimental_useFormStatus` abil

Vormid on veebisuhtluse alustala. Alates lihtsast uudiskirjaga liitumisest kuni keeruka mitmeastmelise finantsrakenduseni on need peamine kanal, mille kaudu kasutajad meie rakendustega suhtlevad. Ometi on vormi oleku haldamine Reactis aastaid olnud keerukuse, koodikorduse ja sõltuvustest väsimise allikas. Oleme žongleerinud kontrollitud komponentidega, võidelnud olekuhaldusteekidega ja kirjutanud lugematuid `onChange` käsitlejaid, kõik selleks, et saavutada sujuv ja intuitiivne kasutajakogemus.

Reacti meeskond on seda veebiarenduse fundamentaalset aspekti ümber mõelnud, mis on viinud uue ja võimsa paradigma kasutuselevõtuni, mille keskmes on React Server Actions (serveri tegevused). See uus mudel, mis on üles ehitatud progressiivse täiustamise põhimõtetele, püüab lihtsustada vormide käsitlemist, viies loogika lähemale sinna, kuhu see kuulub – sageli serverisse. Selle kliendipoolse revolutsiooni keskmes on kaks uut eksperimentaalset hook'i: `useFormState` ja meie tänase arutelu täht, `experimental_useFormStatus`.

See põhjalik juhend viib teid sügavale `experimental_useFormStatus` hook'i maailma. Me ei vaata ainult selle süntaksit, vaid uurime ka vaimset mudelit, mida see võimaldab: olekupõhine valideerimisloogika. Saate teada, kuidas see hook eraldab kasutajaliidese vormi olekust, lihtsustab ootel olekute haldamist ja töötab koos serveri tegevustega, et luua robustseid, ligipääsetavaid ja ülijõudsaid vorme, mis töötavad isegi enne JavaScripti laadimist. Olge valmis ümber mõtlema kõik, mida arvasite teadvat Reactis vormide ehitamisest.

Paradigmamuutus: Reacti vormide areng

Et täielikult hinnata uuendust, mille `useFormStatus` toob, peame esmalt mõistma vormihalduse teekonda Reacti ökosüsteemis. See kontekst toob esile probleemid, mida see uus lähenemine elegantselt lahendab.

Vana koolkond: kontrollitud komponendid ja kolmandate osapoolte teegid

Aastaid oli Reactis vormide standardne lähenemine kontrollitud komponendi muster. See hõlmab:

• Reacti olekumuutuja (nt `useState` abil saadud) kasutamine iga vormisisendi väärtuse hoidmiseks.
• `onChange` käsitleja kirjutamine oleku uuendamiseks iga klahvivajutuse peale.
• Olekumuutuja tagasi andmine sisendi `value` prop'ile.

Kuigi see annab Reactile täieliku kontrolli vormi oleku üle, lisab see märkimisväärselt koodikordust. Kümne väljaga vormi jaoks võib vaja minna kümmet olekumuutujat ja kümmet käsitlejafunktsiooni. Valideerimise, veaolukordade ja esitamise oleku haldamine lisab veelgi keerukust, mis viib arendajad sageli looma keerukaid kohandatud hook'e või kasutama ulatuslikke kolmandate osapoolte teeke.

Teegid nagu Formik ja React Hook Form said tuntuks, abstraheerides selle keerukuse. Need pakuvad suurepäraseid lahendusi oleku haldamiseks, valideerimiseks ja jõudluse optimeerimiseks. Siiski kujutavad need endast veel üht hallatavat sõltuvust ja töötavad sageli täielikult kliendi poolel, mis võib viia valideerimisloogika dubleerimiseni frontend'i ja backend'i vahel.

Uus ajastu: progressiivne täiustamine ja serveri tegevused

React Server Actions (serveri tegevused) toovad kaasa paradigmamuutuse. Põhiidee on ehitada veebiplatvormi vundamendile: standardsele HTML-i `

` elemendile. Serveri tegevusega vorm töötab nagu klassikaline HTML-vormi esitamine – see võib toimida ideaalselt isegi siis, kui JavaScript ebaõnnestub või on keelatud. See on progressiivse täiustamise olemus.

Kui JavaScript laeb, kaaperdab React vormi esitamise protsessi, vältides lehe täielikku uuesti laadimist ja käivitades serveri tegevuse asünkroonselt. See annab meile mõlemast maailmast parima: serveris renderdatud rakenduste vastupidavuse ja ühe lehe rakenduse (SPA) rikkaliku ja interaktiivse kogemuse.

See mudel viib äriloogika ja valideerimise tõe allika tagasi serverisse (või serverilaadsesse keskkonda). Kliendipoolne kood muutub lihtsamaks, tegeledes peamiselt kasutajaliidese renderdamisega, mis põhineb selle serverisuhtluse *olekul*. Just siin tuleb mängu `useFormStatus`.

Kapoti all: Mis on `experimental_useFormStatus`?

Hook `experimental_useFormStatus` on kliendipoolne tööriist, mis on loodud pakkuma teavet vanem-`<form>` elemendi viimase esitamise kohta. See on ainult lugemiseks mõeldud hook, mis annab komponendile teada kõik, mida see peab teadma vormi esitamise oleku kohta, ilma et talle oleks vaja edasi anda mingeid prop'e.

Põhifunktsionaalsus

Kujutage ette esitamisnuppu suures vormis. Kuidas see nupp teab, millal vormi esitatakse? Traditsiooniliselt peaksite edasi andma olekumuutuja nagu `isSubmitting` läbi mitme komponendikihi (prop drilling). `useFormStatus` abil saab nupu komponent selle teabe ise teada.

Seda hook'i tuleb kutsuda komponendist, mis renderdatakse *seespool* `<form>` elementi. Seejärel pakub see olekuteavet just selle konkreetse vormi elutsükli kohta.

`useFormStatus` hook'i anatoomia

Kui kutsute välja `const status = useFormStatus()`, saate tagasi objekti järgmiste võtmeomadustega:

• `pending` (boolean): See on kõige sagedamini kasutatav omadus. See on `true`, kui vanemvormi parajasti esitatakse, ja vastasel juhul `false`. See sobib ideaalselt nuppude keelamiseks, laadimisindikaatorite näitamiseks või ootel olekute stiilimiseks.
• `data` (FormData): Objekt, mis rakendab `FormData` liidest. See sisaldab andmeid, mis vormiga esitati. See on uskumatult kasulik optimistlike kasutajaliidese uuenduste rakendamiseks – näiteks kasutaja kommentaari koheseks kuvamiseks loendis pärast selle esitamist, isegi enne kui server on selle loomist kinnitanud.
• `method` (string): HTTP-meetod ('get' või 'post'), mida vormi esitamiseks kasutati.
• `action` (function): Viide serveri tegevuse funktsioonile, mis esitamise ajal käivitati.

Kuldreegel: `<form>` elemendi laps

Oluline reegel, mida meeles pidada, on see, et komponent, mis kasutab `useFormStatus`'i, peab olema renderdatud jälgitava `<form>` elemendi lapsena. See ei saa olla samas komponendis, mis renderdab `<form>` märgendit ennast, sest see peab pääsema juurde vormi kontekstile. Seetõttu näete peaaegu alati, et komponendid nagu `` luuakse eraldi, et majutada `useFormStatus`'i loogikat.

Lihtne näide: nutikas esitamisnupp

Vaatame kõige levinumat kasutusjuhtu tegevuses. Standardse `<button>` asemel loome komponendi, mis on teadlik vormi esitamise olekust.

Fail: SubmitButton.js

import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton() { const { pending } = useFormStatus(); return ( {pending ? 'Esitan...' : 'Registreeru'} ); }

Fail: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // Serveri tegevus export function SignUpForm() { return ( E-post:
); }

Selles näites on `SubmitButton` täiesti iseseisev. See ei saa ühtegi prop'i. See kasutab `useFormStatus`'i, et teada, millal `SignUpForm` on ootel, ning keelab automaatselt ennast ja muudab oma teksti. See on võimas muster lahtisidumiseks ja korduvkasutatavate, vormiteadlike komponentide loomiseks.

Asja tuum: olekupõhine valideerimisloogika

Nüüd jõuame põhikontseptsioonini. `useFormStatus` ei ole ainult laadimisolekute jaoks; see on peamine võimaldaja teistsugusele mõtteviisile valideerimisest.

"Olekupõhise valideerimise" defineerimine

Olekupõhine valideerimine on muster, kus valideerimise tagasiside antakse kasutajale peamiselt vastusena vormi esitamise katsele. Selle asemel, et valideerida iga klahvivajutuse (`onChange`) või välja fookusest lahkumise (`onBlur`) peale, käivitub peamine valideerimisloogika siis, kui kasutaja vormi esitab. Selle esitamise tulemust – selle *olekut* (nt edu, valideerimisviga, serveri viga) – kasutatakse seejärel kasutajaliidese uuendamiseks.

See lähenemine sobib ideaalselt React Server Actions'iga. Serveri tegevusest saab valideerimise ainus tõe allikas. See võtab vastu vormi andmed, valideerib need teie äriloogika reeglite vastu (nt "kas see e-posti aadress on juba kasutusel?") ja tagastab struktureeritud olekuobjekti, mis näitab tulemust.

Selle partneri roll: `experimental_useFormState`

`useFormStatus` ütleb meile, *mis* toimub (ootel), kuid see ei ütle meile, *mis oli tulemus*. Selleks vajame selle sõsar-hook'i: `experimental_useFormState`.

`useFormState` on hook, mis on loodud oleku uuendamiseks vormi tegevuse tulemuse põhjal. See võtab argumendiks tegevusfunktsiooni ja algse oleku ning tagastab uue oleku ja pakendatud tegevusfunktsiooni, mille saate oma vormile edasi anda.

const [state, formAction] = useFormState(myAction, initialState);

• `state`: See sisaldab `myAction`'i viimase käivitamise tagastusväärtust. Siit saame oma veateated.
• `formAction`: See on teie tegevuse uus versioon, mille peaksite edastama `<form>` elemendi `action` prop'ile. Kui see käivitatakse, kutsub see esile algse tegevuse ja uuendab `state`'i.

Kombineeritud töövoog: klõpsust tagasisideni

Siin on, kuidas `useFormState` ja `useFormStatus` töötavad koos, et luua täielik valideerimistsükkel:

1. Algne renderdamine: Vorm renderdatakse `useFormState`'i pakutud algse olekuga. Vigu ei kuvata.
2. Kasutaja esitamine: Kasutaja klõpsab esitamisnupul.
3. Ootel olek: Esitamisnupu `useFormStatus` hook teatab kohe `pending: true`. Nupp muutub keelatuks ja näitab laadimisteate.
4. Tegevuse täitmine: Serveri tegevus (mida `useFormState` ümbritseb) käivitatakse vormi andmetega. See teostab valideerimise.
5. Tegevuse tagastus: Tegevus ebaõnnestub valideerimisel ja tagastab olekuobjekti, näiteks:
   `{ message: "Valideerimine ebaõnnestus", errors: { email: "See e-posti aadress on juba võetud." } }`
6. Oleku uuendamine: `useFormState` saab selle tagastusväärtuse ja uuendab oma `state` muutujat. See käivitab vormikomponendi uuesti renderdamise.
7. Kasutajaliidese tagasiside: Vorm renderdatakse uuesti. `pending` olek `useFormStatus`'ist muutub `false`'ks. Komponent saab nüüd lugeda `state.errors.email` väärtust ja kuvada veateate e-posti sisendvälja kõrval.

Kogu see voog pakub kasutajale selget, serveri poolt autoriteetset tagasisidet, mis on täielikult ajendatud esitamise olekust ja tulemusest.

Praktiline meistriklass: mitme väljaga registreerimisvormi ehitamine

Kinnistame need kontseptsioonid, ehitades täieliku, tootmisstiilis registreerimisvormi. Kasutame valideerimiseks serveri tegevust ning nii `useFormState`'i kui ka `useFormStatus`'i, et luua suurepärane kasutajakogemus.

1. samm: serveri tegevuse defineerimine koos valideerimisega

Esiteks vajame oma serveri tegevust. Tugevaks valideerimiseks kasutame populaarset teeki Zod. See tegevus asub eraldi failis, mis on märgistatud direktiiviga `'use server';`, kui kasutate raamistikku nagu Next.js.

Fail: actions/authActions.js

'use server'; import { z } from 'zod'; // Valideerimisskeemi defineerimine const registerSchema = z.object({ username: z.string().min(3, 'Kasutajanimi peab olema vähemalt 3 tähemärki pikk.'), email: z.string().email('Palun sisestage kehtiv e-posti aadress.'), password: z.string().min(8, 'Parool peab olema vähemalt 8 tähemärki pikk.'), }); // Meie vormi algse oleku defineerimine export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. Vormi andmete valideerimine const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. Kui valideerimine ebaõnnestub, tagastage vead if (!validatedFields.success) { return { message: 'Valideerimine ebaõnnestus. Palun kontrollige välju.', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (Simuleerimine) Kontrollige, kas kasutaja on juba andmebaasis olemas // Päris rakenduses teeksite siin andmebaasi päringu. if (validatedFields.data.email === 'user@example.com') { return { message: 'Registreerimine ebaõnnestus.', errors: { email: ['See e-posti aadress on juba registreeritud.'] }, }; } // 4. (Simuleerimine) Looge kasutaja console.log('Kasutaja loomine:', validatedFields.data); // 5. Tagastage edukas olek // Päris rakenduses võiksite siin suunata kasutades `redirect()` 'next/navigation' teegist return { message: 'Kasutaja on edukalt registreeritud!', errors: {}, }; }

See serveri tegevus on meie vormi aju. See on iseseisev, turvaline ja pakub selget andmestruktuuri nii edu- kui ka veaolukordade jaoks.

2. samm: korduvkasutatavate, olekuteadlike komponentide ehitamine

Et hoida meie põhivormi komponent puhtana, loome spetsiaalsed komponendid meie sisendväljade ja esitamisnupu jaoks.

Fail: components/SubmitButton.js

'use client'; import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton({ label }) { const { pending } = useFormStatus(); return ( {pending ? 'Töötlen...' : label} ); }

Pange tähele `aria-disabled={pending}` kasutamist. See on oluline ligipääsetavuse praktika, mis tagab, et ekraanilugejad teatavad keelatud olekust korrektselt.

3. samm: põhivormi kokkupanek `useFormState` abil

Nüüd toome kõik kokku meie põhivormi komponendis. Kasutame `useFormState`'i, et ühendada meie kasutajaliides `registerUser` tegevusega.

Fail: components/RegistrationForm.js

'use client'; import { experimental_useFormState as useFormState } from 'react-dom'; import { registerUser, initialState } from '../actions/authActions'; import { SubmitButton } from './SubmitButton'; export function RegistrationForm() { const [state, formAction] = useFormState(registerUser, initialState); return (

Registreeri

{state?.message && !state.errors &&

{state.message}

} {state?.message && state.errors &&

{state.message}

}

Kasutajanimi {state?.errors?.username && (

{state.errors.username[0]}

)}

E-post {state?.errors?.email && (

{state.errors.email[0]}

)}

Parool {state?.errors?.password && (

{state.errors.password[0]}

)}

); }

See komponent on nüüd deklaratiivne ja puhas. See ei halda ise ühtegi olekut, peale `useFormState`'i pakutud `state` objekti. Selle ainus ülesanne on renderdada kasutajaliides selle oleku põhjal. Nupu keelamise loogika on kapseldatud `SubmitButton`'i sisse ja kogu valideerimisloogika asub failis `authActions.js`. See murede lahusus on tohutu võit hooldatavuse seisukohast.

Edasijõudnud tehnikad ja professionaalsed parimad tavad

Kuigi põhimuster on võimas, nõuavad reaalmaailma rakendused sageli rohkem nüansse. Uurime mõningaid edasijõudnud tehnikaid.

Hübriidlähenemine: kohese ja esitamisjärgse valideerimise ühendamine

Olekupõhine valideerimine on suurepärane serveripoolsete kontrollide jaoks, kuid võrguringreisi ootamine, et öelda kasutajale, et tema e-posti aadress on kehtetu, võib olla aeglane. Sageli on parim hübriidlähenemine:

• Kasutage HTML5 valideerimist: Ärge unustage põhitõdesid! Atribuudid nagu `required`, `type="email"`, `minLength` ja `pattern` pakuvad kohest, brauseripõhist tagasisidet ilma lisakuludeta.
• Kerge kliendipoolne valideerimine: Puhtalt kosmeetiliste või vorminduskontrollide jaoks (nt parooli tugevuse indikaator) saate endiselt kasutada minimaalses koguses `useState` ja `onChange` käsitlejaid.
• Serveripoolne autoriteet: Jätke serveri tegevus kõige kriitilisema, äriloogika valideerimise jaoks, mida ei saa kliendi poolel teha (nt unikaalsete kasutajanimede kontrollimine, andmebaasi kirjete vastu valideerimine).

See annab teile mõlemast maailmast parima: kohese tagasiside lihtsate vigade korral ja autoriteetse valideerimise keerukate reeglite jaoks.

Ligipääsetavus (A11y): vormide ehitamine kõigile

Ligipääsetavus ei ole läbiräägitav. Olekupõhise valideerimise rakendamisel pidage silmas järgmisi punkte:

• Teavitage vigadest: Meie näites kasutasime veateadete konteineritel `aria-live="polite"`. See käsib ekraanilugejatel teatada veateatest kohe, kui see ilmub, ilma kasutaja praegust voogu katkestamata.
• Seostage vead sisendväljadega: Tugevama ühenduse loomiseks kasutage `aria-describedby` atribuuti. Sisendväli saab viidata oma veateate konteineri ID-le, luues programmilise seose.
• Fookuse haldamine: Pärast vigadega esitamist kaaluge fookuse programmilist viimist esimesele kehtetule väljale. See säästab kasutajaid vajadusest otsida, mis valesti läks.

Optimistlik kasutajaliides `useFormStatus`'i `data` omadusega

Kujutage ette sotsiaalmeediarakendust, kus kasutaja postitab kommentaari. Selle asemel, et näidata sekundiks laadimisindikaatorit, saate muuta rakenduse hetkeliseks. `useFormStatus`'i `data` omadus sobib selleks ideaalselt.

Kui vorm esitatakse, muutub `pending` tõeseks ja `data` täidetakse esitamise `FormData`'ga. Saate selle `data` abil kohe renderdada uue kommentaari ajutises, 'ootel' visuaalses olekus. Kui serveri tegevus õnnestub, asendate ootel kommentaari lõplike andmetega serverist. Kui see ebaõnnestub, saate ootel kommentaari eemaldada ja näidata viga. See muudab rakenduse uskumatult reageerimisvõimeliseks.

"Eksperimentaalsetes" vetes navigeerimine

On ülioluline käsitleda "experimental" eesliidet `experimental_useFormStatus`'is ja `experimental_useFormState`'is.

Mida "eksperimentaalne" tegelikult tähendab

Kui React märgistab API eksperimentaalseks, tähendab see:

• API võib muutuda: Nimi, argumendid või tagastusväärtused võivad tulevases Reacti versioonis muutuda, järgimata standardset semantilist versioonimist (SemVer) murranguliste muudatuste osas.
• Võib esineda vigu: Uue funktsioonina võib sellel olla äärmuslikke juhtumeid, mis ei ole veel täielikult mõistetud või lahendatud.
• Dokumentatsioon võib olla napp: Kuigi põhikontseptsioonid on dokumenteeritud, võivad üksikasjalikud juhendid edasijõudnud mustrite kohta alles areneda.

Millal kasutusele võtta ja millal oodata

Niisiis, kas peaksite seda oma projektis kasutama? Vastus sõltub teie kontekstist:

• Sobib hästi: Isiklike projektide, sisemiste tööriistade, idufirmade või meeskondade jaoks, kes on harjunud võimalike API muudatustega toime tulema. Selle kasutamine raamistikus nagu Next.js (mis on need funktsioonid integreerinud oma App Routerisse) on üldiselt turvalisem valik, kuna raamistik aitab osa muutustest abstraheerida.
• Kasutage ettevaatusega: Suuremahuliste ettevõtterakenduste, missioonikriitiliste süsteemide või pikaajaliste hoolduslepingutega projektide puhul, kus API stabiilsus on esmatähtis. Sellistel juhtudel võib olla mõistlik oodata, kuni hook'id on ülendatud stabiilseks API-ks.

Hoidke alati silm peal ametlikul Reacti blogil ja dokumentatsioonil, et saada teateid nende hook'ide stabiliseerimise kohta.

Kokkuvõte: vormide tulevik Reactis

`experimental_useFormStatus`'i ja sellega seotud API-de kasutuselevõtt on midagi enamat kui lihtsalt uus tööriist; see kujutab endast filosoofilist nihet selles, kuidas me Reactiga interaktiivseid kogemusi loome. Võttes omaks veebiplatvormi alused ja paigutades olekupõhise loogika serverisse, saame ehitada rakendusi, mis on lihtsamad, vastupidavamad ja sageli ka jõudsamad.

Oleme näinud, kuidas `useFormStatus` pakub puhast ja lahtisidestatud viisi, kuidas komponendid saavad reageerida vormi esitamise elutsüklile. See välistab prop'ide edasiandmise ootel olekute jaoks ja võimaldab elegantseid, iseseisvaid kasutajaliidese komponente nagu nutikas `SubmitButton`. Koos `useFormState`'iga avab see võimsa olekupõhise valideerimise mustri, kus server on ülim autoriteet ja kliendi peamine vastutus on renderdada serveri tegevuse tagastatud olekut.

Kuigi "eksperimentaalne" märgis nõuab teatavat ettevaatust, on suund selge. Vormide tulevik Reactis on progressiivne täiustamine, lihtsustatud olekuhaldus ning võimas ja sujuv integratsioon kliendi ja serveri loogika vahel. Õppides neid uusi hook'e täna, ei õpi te lihtsalt uut API-d; te valmistute järgmise põlvkonna veebirakenduste arenduseks Reactiga.